home *** CD-ROM | disk | FTP | other *** search
/ FishMarket 1.0 / FishMarket v1.0.iso / fishies / 051-075 / disk_069 / conman / conman.doc < prev    next >
Text File  |  1992-05-06  |  8KB  |  152 lines

  1. *************************     ConMan v0.9     **************************
  2.  
  3. ConMan is a replacement console handler that provides line editing and
  4. command line histories.  It runs under AmigaDOS (V1.1 or V1.2) and is
  5. completely transparent to any application program that uses CON: windows.
  6. Programs that use RAW: input are unaffected.
  7.  
  8. Once installed, any windows opened by AmigaDOS will automatically open
  9. using the ConMan handler.  This includes command windows opened by 
  10. NEWCLI as well as any data input/output windows that your program uses.
  11.  
  12. Line Editing.
  13. The DELETE and BACKSPACE keys function in the usual manner.  The arrow keys
  14. may be used for cursor positioning.  The shifted left arrow moves the cursor
  15. to the beginning of the line, and the shift right arrow moves to the end.  
  16.  
  17. The default input mode inserts characters at the cursor; overstrike may 
  18. be toggled by CTRL-A.  CTRL-X deletes the whole line, while CTRL-Y
  19. deletes from the cursor position to the end of the line.
  20. Tabs are replaced by blanks, so you can back up over them properly.
  21.  
  22. Command History.
  23. Previously-entered lines may be recalled using the up-arrow.  Lines are
  24. retrieved sequentially; if you go past the one you want, the down-arrow
  25. key will back up one.  Shift up-arrow goes to the oldest line, and shift
  26. down-arrow positions the pointer to the most recent line.  The current
  27. history buffer holds ten input lines; this will be made variable in a 
  28. later release.
  29.  
  30. Window definition.
  31. ConMan supports the usual DOS window specification string.  For example,
  32. "CON:160/50/320/100/MyWindow" specifies a window 320x100 pixels in size,
  33. beginning in position (160,50).  ConMan also accepts a specification in
  34. the form "CON:x20480", where the hex digits following the "x" are the
  35. absolute address of an Intuition window pointer.  If you're writing in
  36. 'C', the following sequence would serve to open a window and attach a
  37. DOS console to it:
  38.  
  39.       window = OpenWindow(&newwindow);   /* get a window          */
  40.       sprintf(buffer,"CON:X%x",window);  /* build the name string */
  41.       file  = Open(buffer,MODE_OLDFILE); /* open a console stream */ 
  42.  
  43. The more arcane method of passing the window pointer to the handler
  44. (as in Andy Finkel's Window example) should also work, but I haven't
  45. tried it yet. (Let me know, if someone tries it).
  46.  
  47. Late-breaking news: at the suggestion of John Toebes, I've added the
  48. ability to select which gadgets and attributes your window will have.
  49. Here's how it works:  After the last numeric parameter, put a backslash
  50. and any of the attribute options:
  51.    A ==> activate             (def: no activate)
  52.    B ==> BackDrop             (def: not BackDrop)
  53.    C ==> Close gadget         (def: no gadget) (action not implemented)
  54.    D ==> Depth gadget         (def: depth gadget)
  55.    M ==> Move (drag) gadget   (def: drag gadget)
  56.    N ==> NoBorder             (def: border) (sorry, 'B' was used)
  57.    S ==> Sizing gadget        (def: sizing gadget)
  58.    Z ==> Zero-Zero            (def: not GZZ) (does anybody use this?)
  59. Each attribute serves to TOGGLE the corresponding windows flag, so adding
  60. it twice will cancel the effect.  Follow the list with a terminating '/'
  61. and an optional title.
  62.  
  63. Example: CON:10/10/300/100\nb/       creates a borderless backdrop window.
  64.          CON:10/10/300/100\acm/Fixed creates an active window, with a
  65.                                      close gadget, that won't budge.
  66.  
  67. One more addition: specifying CON:s123abc/10/10/300/100/ will attach
  68. your window to the specified CUSTOMSCREEN.  I only tried it on the
  69. workbench screen, though (by digging the screen pointer out of
  70. IntuitionBase).  Let me know if it works on real custom screens.
  71.  
  72. Installation.
  73. ConMan requires that two files be copied to your SYS: disk (don't worry,
  74. they're both small.)  "My-Handler" (144 bytes) must be placed in
  75. the SYS:L directory, to keep all those bigger handlers company.  The
  76. "conhandlerlib.library" (4164 bytes) must be placed in the your LIBS:
  77. directory, which is normally SYS:LIBS.  Once these files are present,
  78. execute ConMan (852 bytes) to install the handler.  This file only needs
  79. to be run once (e.g. from your startup-sequence); it allocates 20 bytes
  80. of memory for the handler name string which won't be returned (there are
  81. no provisions in DOS for removing handlers, anyway.)  The ARCed files
  82. have shortened names, so be sure to rename "conlib.lib" and "myhandlr."
  83. A simple "install" script is included to copy files.
  84.  
  85. Distribution.
  86. This program is to be distributed as shareware to Amigoid life-forms 
  87. everywhere!  Make sure your friends get a copy.  Comments and contributions
  88. will be appreciated and may be sent to:
  89.  
  90.       William S. Hawes
  91.       P.O. Box 308
  92.       Maynard, MA 01754
  93.       (617) 568-8695
  94.  
  95. Further Notes.
  96. This Beta version still has some debugging code in it.  Function key F1
  97. toggles a flag that causes a DisplayBeep everytime a WaitForChar packet
  98. is dispatched.  Most programs will not use the WaitForChar function,
  99. since a Read to a CON: device will block until characters are available
  100. anyway.  F2 toggles a flag that DisplayBeeps whenever a "break" signal is
  101. passed on (i.e. is applied to your hapless task).
  102.  
  103. The program was developed and tested under V1.2; at least one V1.1
  104. dependency was found and fixed (DoIO to the console device scratched D7).
  105. Let me know if other problems exist.  I spent a lot of time making it
  106. work using the DOS handler-loading mechanism so that it would be backwards
  107. compatible.
  108.  
  109. ConMan does not pre-allocate a history buffer for the commands, but
  110. rather allocates just enough for each string.  This means that the 
  111. available memory changes after every command ... the memory isn't lost,
  112. but it makes it difficult to tell if a program under development is
  113. misbehaving.  This will be changed in the next release.
  114.  
  115. Some of the things I'm thinking about adding include:
  116.    -- Support for the function keys and help keys.  I'm designing a 
  117.       general-purpose data structure to support context-sensitive 
  118.       function and help key definitions.  Keys should support both
  119.       string-substitution and event-type actions.  Any ideas in these
  120.       directions?
  121.  
  122.    -- The ConMan handler is built as a standard shared library.  Various
  123.       entry points will be brought out and documented, and procedural
  124.       calls will be available to manipulate the internal data structures.
  125.       This will allow you to retrieve the window pointer by something
  126.       straightforward like "window = ConsoleWindow(filehandle);".
  127.       I may even write the binding routines for calls from 'C' ... 
  128.  
  129.    -- How about adding a "dynamic piping" capability, so that an I/O
  130.       stream could be diverted on the fly into (or out of) a file?  Ideas?
  131.  
  132.    -- I plan to release the source code (in assembler) once things are
  133.       cleaned up a bit.  It will be very helpful to anyone needing to
  134.       write a DOS handler.  In the meantime, take a look at the included
  135.       "handler.asm" file:  it provides a simple way around the problem 
  136.       of writing BCPL look-alike programs.  
  137.  
  138.    -- Another tip:  debugging handlers is easy if you try the following 
  139.       trick.  Run the handler program as a normal process under your 
  140.       favorite debugger.  Have it open a public message port, which can
  141.       located by a test driver running separately.  The driver now 
  142.       installs your processid ("pr_MsgPort, obtained by following the
  143.       MP_SIGTASK trail from your public port) in its "pr_ConsoleTask" slot,
  144.       and then does an Open('*',MODE_OLDFILE).  Voila!  Any I/O done by
  145.       the driver comes under the scrutiny of your debugger.  You can 
  146.       get things working before having to worry about installing the
  147.       handler in a device node.  (An occasional message collision will
  148.       occur, since the debugger is probably doing I/O through the 
  149.       processid message port.  Not to worry ...)
  150.  
  151.                                    -- WSH (4/14/87)
  152.